Ceph性能测试续 - 附：选型建议、上一篇答疑
在上周发表了《Ceph性能测试：纠删码 vs. 三副本》之后，有幸收到了一些同行朋友们的反馈。下面大致总结了几个问题，以我有限的技术能力做个答复吧。
1、Ceph的纠删码目前主要是应用于对象存储吧，有用在块上吗？
引用自XSKY瞿天善的PPT《EC OVERWRITE 进展》
如上图，目前纠删码（Erasure Code）更多用于冷数据。前两年听阿里巴巴技术专家张友东讲过，淘宝TFS是在三副本和纠删码之间按策略分层迁移，国内也有其他互联网公司是类似的用法。而HDFS应用的特点是大数据块顺序读写。
我在上一篇中引用的测试数据是按照radosbench块访问来进行的，估计这样更容易直接反映出EC和Replica的性能差异吧。而测试环境推荐的用途应该是对象存储，比如那3台R630服务器节点就兼具MON和RGW（对象存储网关）的功能。
而今，纠删码已经开始走进一些Server SAN和超融合产品，比如VMware VSAN（详见：《全闪存专享：VSAN 6.2重复数据删除、纠删码浅析》）和Nutanix，在这方面开源比商业软件慢一些也是正常的。Ceph的EC能否良好应用于块存储，还取决于另外一点——对overwrite（覆盖写）的支持，上周国内知名Ceph专家王豪迈在《Vol 56 | EC Update 进展》中就谈到了相关内容。
我们知道，对象存储的RESTful语义支持Get（读）、Put（写）、Delete（删除），而没有覆盖/部分改写，这样对于纠删码是比较友好的。经过我与豪迈确认，K版本Ceph已经支持overwrite，但是还是试验特性。可以说EC应用于通用块设备应该不远了。
2、如果说在EC Pool的上层需要一个Rep（副本）的Cache Pool，短时间的测试能看出差别吗？
上图引用自王豪迈在一年多以前的分享《Ceph的现在和未来》，可以看到Ceph针对EC的分层设计。无论Writeback还是Writethrough数据都躲不开副本模式的CachePool，一方面短时间的写入可能不会真正落到后端EC Pool，另外听说还有个比较麻烦的设计——读取EC Pool中的数据也需要先移动到Cache Pool。
就这一点我也请教了豪迈，K版本Ceph对于纠删码已经不用前置Cache Pool了。另外，“按照最近Sage 的邮件来看，K 版本的正式发布估计要延迟到 1 月底”。
上图引用自SUSE Alex Lau（劉俊賢）的PPT《Bring Ceph to Enterprise》
3、Ceph OSD节点两个网口分别用于前后端的话，如何容错？
这确实是个问题，上一篇中描述的环境配置，建议用于测试环境。
引用自技术白皮书《Dell PowerEdge R730xd Performance and Sizing Guide for Red Hat CephStorage》
上图是本文将要介绍的另一个测试环境。OSD存储节点使用了5台2U的Dell PowerEdge R730xd，同样有3台1U的R630 MON/RGW节点，客户端负载跑在10台R220服务器上。
这里的网络配置同样划分了前后端，分别走不同的交换机，所以有单点故障。如果是生产部署，将前后端网络各分配2个万兆网口固然理想，但成本也会高一些。所以，实际应用中将双网口绑定兼跑前后端流量的估计也不少。
我从这几天看到的《详解VxRail超融合产品的软硬件功能》中引用了上面这张图作为参考，可以看到VSAN使用NIC 1作为Active、NIC 2Standby，而虚拟机和其它逻辑网络则是NIC 2Active、NIC 1 Standby。
解释完上面3个问题，我给大家讲讲更多的测试数据。首先，还有几位朋友希望能给一些Ceph硬件配置的建议。
其实之前我也看别的专家给出过类似的建议，这只是一个相对通用的参考，比如也有人推荐1.5GHz CPU Core per OSD等。我们知道PCIe/NVMe SSD性能出众，那么1块NVMe就可以顶替3-4个SATA/SAS SSD用于Journal日志盘吗？
12HDD+3 SATA SSD对比16 HDD+1NVMe SSD
在这份测试报告中，一共对比了5套配置。除了在前一篇中已经对比过的三副本/纠删码之外，还有不同的驱动器配比。PowerEdge R730xd2U服务器除了背侧2个2.5英寸驱动器位（系统盘）之外，最多支持16个3.5英寸驱动器位，在使用IntelP3700 AIC扩展卡作为Journal设备时可以满配16块数据盘；而如果换成Intel S3710 SSD则会占用3个SATA位，剩下硬盘配置12块比较合适，这样就造成了OSD裸容量的不同。
此外，该测试该对比了一点：PERC RAID卡对HDD硬盘配置单盘RAID和JBOD直通模式之间的性能差别。
在《大数据存储硬件选型分析》一文中我曾经介绍过上图——R730xd机箱支持12+2+4的配置（带有Flexbay和Mid-bay）。在2U机箱的中部增加了4个3.5英寸硬盘位，因此3.5英寸数据盘的数量达到16块。
先活动下身子骨——服务器子系统Baseline测试
在进行Ceph测试之前给服务器做个基础性能体检，是个不错的习惯：）上面针对CPU、网卡、SAS硬盘、SATA和NVMe SSD分别使用了linpack、iperf和fio这几种测试工具。
首先看CPU浮点性能，Xeon E5-2630v3是8核2.4GHz，E5-2650 v3是10核2.3GHz（Cache容量也更大），而双核的G1820 CPU只是用在R220客户端上，这里不用太在意它。
网卡带宽这个比较重要，可以看到Intel X520LOM在三款服务器上都能达到接近万兆每秒的性能。
接着是XFS文件系统上的硬盘/SSD性能。希捷SAS硬盘表现正常，NVMeSSD的读IOPS和带宽都达到了SATA的4-5倍；写IOPS P3700接近S3700的2倍，而写带宽测试结果也相差5倍以上。
注：以上测试的IOPS是随机读写，而实际Journal用途则接近于顺序读写。
读写带宽、单位容量成本对比
上面表格列出的每OSD服务器节点的吞吐带宽：
1、 读方面3副本可达1100-1200MB/s，接近万兆网卡的上限。关于Ceph这方面的原理我在《Ceph性能测试：纠删码 vs. 三副本》中简单介绍过。
2、 同样是EC3+2配置，16+0和16+1的区别就差在是否使用NVMeSSD做Journal。我们看到读写带宽都有一定的差距，我觉得这里面有读命中的情况，同时也证明了SSD Journal对性能的帮助。
3、 写带宽的高低排序，分别为16+1EC 3+2、16+0 EC 3+2、16r+1 3xRep、16j+1 3xRep和12+3 3xRep。同为三副本，NVMe SSD Journal的效果比3块SATA SSD好，每个硬盘配置RAID的表现比JBOD模式好。
这个对比是单位容量的价格，结论大致如下：
1、 EC8+3比EC3+2便宜，这个和RAID数据盘/校验盘的比例是一样的道理，但性能有时可能是反过来的情况；
2、 不用NVMe SSDJournal能便宜一点；
3、 三副本相对最贵，其中12+3配置减少了每服务器支持的硬盘数，单位容量成本更高一点。
JBODvs. RAID0：写缓存对机械盘有帮助
副本对比纠删码保护，这个结果与上一篇4U 90盘位DSS7000（2个45x 3.5”盘位节点）配置符合同样的规律，我就不重复分析了。
前面列出了16+1配置的JBOD和单盘RAID0对比，这里再看三副本也是同样的情况。每服务器节点读带宽基本相同，而写带宽单盘RAID0比JBOD直通大约高出15%。可见在Ceph中RAID卡上带电池保护的Cache还是有点用处的。
服务器选型建议：吞吐优化、成本/容量优化节点
上表是Dell针对吞吐优化型（大数据块读写）和成本/容量优化型推荐的Ceph服务器配置，集群容量都是指硬盘裸容量。
- 100TB+“超小规模”可以用大于4台R730xd三副本，16块6TB硬盘加一个800GBNVMe SSD；
- 500TB+小规模增加8台以上R730xd三副本；
- 1PB+中等规模偏冷数据可选择15台以上R730xd 8:3纠删码，HDD单盘增大到8TB。
以上只是一个参考，用户也可以根据实际情况选择别的服务器，比如我以前也用过小品牌3U 16盘的机型，密度上会低一些。
当然还有上一篇中提到的DSS7000，针对1.5PB+大规模成本/容量优化型用途设计。3台4U机箱就是6节点，270块8TB硬盘，40GbE网口我觉得应该是每45盘位节点2个（不排除这里笔误）。
本文到此先告一段落，还缺点什么呢，没有看到IOPS测试和对应的优化型配置？等后续有了资料我第一时间分享给大家。
参考资料
《Dell PowerEdge R730xd Performance and Sizing Guide for Red Hat CephStorage》
http://en.community.dell.com/techcenter/cloud/m/dell_cloud_resources/20442913/download
注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。进一步交流技术，可以加我的QQ/微信：490834312。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）
尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！《企业存储技术》微信公众号：huangliang_storage
长按二维码可直接识别关注
历史文章汇总（传送门）：http://chuansong.me/account/huangliang_storage